ソフトウェアアーキテクチャの基礎輪読会 13章
日付：2023/11/20
調査者：naoya.icon
章のまとめ
サービスベースアーキテクチャ概要
ドメインによって分割されたアーキテクチャ
分散型のマクロなレイヤード構造をとる
個別に以下のものをデプロイする
1. ユーザーインターフェース
2. 粒度の粗いリモートサービス
3. モノリシックなデータベース
ポイント
サービスはSQLクエリや結合を再利用できる
中央でデータベースを共有する
データベース接続が問題になることがほとんどない
サービス数が少ないため
データベース接続が問題になる
takasshii.iconスケール大変そう〜
基本的にはモノリシックDBだけど、ドメインによって分割する場合もあり、その場合は接続困難、という話ですかね
naoya.icon yes
iNoma.iconnaruhodo !
2のサービスについて
独立して個別にデプロイされる粒度の粗いアプリケーションの一部
通常、単一のモノリシックデータベースを共有
アプリケーションコンテキスト内のサービス数は一般的に4〜12の間で、平均7個程度
ほとんどの場合、各ドメインサービスのインスタンスは１つ
必要に応じて、複数インスタンスが存在することもある→スケーリングが必要なサービスのみ
ユーザーインターフェースとドメインサービスの間に負荷分散機能を必要とする
ユーザーインターフェースが健全で利用可能なサービスインスタンスに向くようにするため
takasshii.icon負荷分散って何するんだ
takasshii.iconDomainの分散か
リモートアクセスプロトコルを利用して、UIからリモートでアクセスされる
→ 異なるクラスやコンポーネントが必要なサービスやオブジェクトにアクセスするための中央集権的なポイントを提供する
トーポロジーの種類(分割の仕方)
ここからは本書の図を見ながら説明していく
1. 単一のモノリシックなUIはドメインごとやドメインサービスごとに分割できる→図13-2
2. 単一のモノリシックなDBは、(マイクロサービスのように)ドメインサービスごとのDBにまで分割できる→図13-3
それぞれのDBが持つデータを他のドメインサービスが必要とないことが前提
ドメインサービス間の通信やDB間のデータの重複を避けれられる
3. UIとサービスの間にリバースプロキシやゲートウェイからなるAPIレイヤーを追加できる→図13-4
以下の場合に有効
ドメインサービスの機能を外部システムに公開
共通の横断的な関心事を統合してUIの外に移動させる
一般的なAPIレイヤー
REST API→HTTPプロトコルを使用してRestfulな通信を行うAPI
GraphQL API→柔軟なクエリ言語を利用し、クライアントが必要なデータのみをリクエストできるようにするAPI
SOAP API→規格されたプロトコルを利用して、XMLベースのメッセージ交換を行うAPI
サービスの設計と粒度
オーケストレーション→トランザクションのワークフローを制御・管理する独立したメディエーターサービスを使用して、複数のサービスを調整する コレオグラフィ→複数のサービスの調整であり、各サービスは中央のメディエーターを使用せずに違いでやり取りする
2つの設計アプローチがある→図13-5
各ドメインサービスをAPIファサード層→ビジネス層→永続化層で分ける
APIファサード→複数のシステムやサービスの背後にある複数のインターフェースや実装を隠蔽して、シンプルで統一されたインターフェースを提供する設計パターン iNoma.icon:naruhodo
各ドメインサービスをドメインごとに分ける
ドメインサービス層は APIアクセス用のAPIファサード層を挟む必要がある
UIがあるビジネス機能を実行するために相互作用するため
APIファサード層は通常、UIからビジネス要求をオーケストレーションする責務を負う
サービスベースアーキテクチャ vs マイクロサービスアーキテクチャ
サービスアーキテクチャのメリット
データの完全性や一貫性は向上する
サービスアーキテクチャのデメリット
一部の些細な変更でサービス全体をテストする必要がある
多くのコードがデプロイされる(1デプロイメントユニットが大きい)ため、何かの機能が壊れるリスクが高まる
データベース分割
通常はサービス数が少ないので、モノリシックなDBを共有する
課題
テーブルスキーマの変更は、テーブルスキーマの変更が適切に行われないすべてのサービスに影響を与える可能性がある→図13-6
データベースの変更が労力と調整面でかなりコストがかかる
サービスベースアーキテクチャでは、データベースのテーブルスキーマを表す共有クラスファイル(エンティティオブジェクト)はすべてのドメインサービスの共有ライブラリに存在する エンティティオブジェクトのための単一共有ライブラリを作成することはサービスベースアーキテクチャを実装する上で、最も効果的な方法
naoya.icon そうしないと、書くドメインサービスで一つ一つ書かないとあかんくなるの地獄や
データベース変更の影響とリスクを低減する方法
データベースを論理的に分割し、論理的な分割を共有ライブラリを介して表現すること→13-7
TIPS：DBの変更をより適切に制御するため、明確なデータドメインを維持しながら、DB内の論理的な分割を可能な限り細かくする
アーキテクチャの具体例紹介
図13-8
移すだけなので、簡単にまとめます
オンラインリサイクルショップのサービス
仕様
商品をいくらで買い取ってもらえるかを企業に問い合わせ(見積もり依頼)
顧客はリサイクル業者に商品を送り、業者は商品を受け取る(受取)
業者は商品の状態を判断(査定)
業者が査定金額を顧客に払う(会計)
このプロセスを常に確認できる(取引状態)
商品を廃棄するか再販する(リサイクル)
企業が資料を臨時または定期で発行(レポーティング)
観点
1. 特定されたドメイン(仕様)ごとにドメインサービスとして実装(デプロイ)
スケーリングが必要なサービスだけスケーリングすれば良い
2. UIがどのドメインに統合されているか
UIの耐障害性、スケーラビリティ、セキュリティを実現
外部の顧客は内部機能のネットワークパスを持たない
3. DBの分割
セキュリティを実現
内部と外部のデータを別のネットワークゾーンにおく
サービスベースアーキテクチャの利点
耐障害性
スケーラビリティ
セキュリティ
アジリティ
テスト容易性
デプロイ容易性
アーキテクチャ特性の評価
table:サービスベースアーキテクチャ
分割タイプ ドメイン
量子数 1(モノリシック)以上
デプロイ容易性 ☆☆☆☆
弾力性 ☆☆
進化性 ☆☆☆
耐障害性 ☆☆☆☆
モジュール性 ☆☆☆☆
全体的なコスト（の安価さ） ☆☆☆☆
パフォーマンス ☆☆☆
信頼性 ☆☆☆☆
スケーラビリティ ☆☆☆
シンプルさ ☆☆☆
テスト容易性 ☆☆☆☆
iNoma.iconつよい
応用
code:sample.kt
質疑応答